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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



This document covers details the architectural requirements for the GSM in lu mode and UMTS systems. In particular it 
details the high level requirements for the Circuit Switched (CS) Domain and the stage 2 procedures that span more 
than one domain/subsystem within UMTS and GSM. The reference model to which these procedures apply can be 
found within 3GPP TS 23.002 [1]. In addition, A mode to lu mode handover for CS services is addressed. Detailed 
architectural requirements within the subsystems are contained within the remainder of the 23 series of specifications 
e.g. the requirements for the Packet Switched (PS) domain are contained within 3GPP TS 23.060 [2] and the 
requirements for the Bearer Independent CS Core Network are contained in 3GPP TS 23.205[14]. 
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Release as the present document. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms defined in 3GPP TR 21.905 [8] apply: 

In lu mode: see 3GPP TR 21.905[8] 

In A/Gb mode: see 3GPP TR 21.905[8] 

RAN: within this document, the term RAN (Radio Access Network) is used to refer to both the UTRAN and GERAN 
in lu mode. RAN specific abbreviations such as URA when used with the term RAN, apply to both UTRAN and 
GERAN in lu mode, unless otherwise stated. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

ATM Aysnchronous Transfer Mode 

CM Connection Management 

CN Core Network 

CS Circuit Switched 

CSCF Call/Session Control Function 

CS-MGW Circuit Switched Media Gateway 

DHCP Dynamic Host Configuration Protocol 

GERAN GSM/EDGE Radio Access Network 

GGSN Gateway GPRS Support Node 

GPRS General Packet Radio Service 

GTP GPRS Tunnelling Protocol 

HLR Home Location Register 

IM IP Multimedia 

IMS IP Multimedia subsystem 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

IPSec IP Security protocol 

LA Location Area 

LAC Location Area Code 

LAN Local Area Network 

LLC Logical Link Control 

LM Location Management 
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MAP Mobile Application Part 

MGCF Media Gateway Control Function 

MGW Media Gateway 

MM Mobility Management 

MRP Media Resource Function 

MSC Mobile Switching Centre 

NAT Network Address Translator 

NGN Next Generation Networks 

OoBTC Out of Band Transcoder Control 

PDA Personal Digital Assistant 

PDP Packet Data Protocol 

PLMN Public Land Mobile Network 

PS Packet Switched 

RA Routing Area 

RAC Routing Area Code 

RAI Routing Area Identifier 

RAN Radio Access Network 

RANAP Radio Access Network Application Part 

RLC Radio Link Control 

RNC Radio Network Controller 

RNTI Radio Network Temporary Identifier 

RRC Radio Resource Control 

SGSN Serving GPRS Support Node 

SIP Session Initiation Protocol 

SRNS Serving Radio Network Subsystem 

SS7 SignalHng System No. 7 

STM Synchronous Transfer Mode 

SGW Signalling gateway 

SRNS Serving Radio Network Subsystem 

TCP Transmission Control Protocol 

TMSI Temporary Mobile Station Identifier 

TrFO Transcoder Free Operation 

UDP User Datagram Protocol 

UE User Equipment 

UMTS Universal Mobile Telecommunications System 

URA UTRAN Registration Area 

UTRAN UMTS Terrestrial Radio Access Network 

VHE Virtual Home Environment 

VLR Visited Location Register 



4 UMTS/GSM domains and subsystems 

4.1 Allowed network and terminal configurations 

A 3GPP network is divided into a radio AN and a CN, which are connected via an open interface over the lu reference 
point. Furthermore, the core network is from a functional point of view divided into a PS Domain, IM Subsystem and a 
CS Domain (see 3GPP TS 23.002 [1]). Any deployment of the IM subsystem requires a PS domain. 

The following network configurations shall be allowed: 

a) networks which provide the functionality of CS Domain and PS Domain (and optionally IM Subsystem); 

b) networks which only provide the functionality of the CS Domain; 

c) networks which only provide the functionality of the PS Domain (and optionally IM Subsystem). 
The following terminal configurations shall be allowed: 

a) terminals which are able to access both to the CS Domain and PS Domain (and optionally IM Subsystem); 

b) terminals which are only able to access to the PS Domain (and optionally IM Subsystem); 
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c) terminals which are only able to access to the CS Domain. 

It shall be noted that a terminal which is only able to access to e.g. the PS Domain supports only mobility management, 
protocols etc. of the that domain. The different configurations given above shall not prevent CS-type services from 
being delivered over the PS domain. 

4.2 Circuit switched (CS) core network domain 

4.2.1 lu mode to lu mode handover for circuit switched services 

For lu mode to lu mode Inter-MSC Hand-Over / SRNS relocation the MAP E interface transporting RANAP messages 
shall be used. Alternatively, in the case of intra-PLMN handover, the GSM to UMTS inter-system handover or SRNS 
relocation between two MSC-areas may be executed as intra-MSC inter-system handover or SRNS relocation 
respectively. In such a case this will be performed by utilising a direct SCCP connection between the target RNC 
located in the target MSC-area and the MSC server already involved in the call. 

For handover of circuit-switched services involving the change of CN equipment (only CS-MGW or CS-MGW and 
MSC-server) the anchor principle shall be applied. 

The first MSC Server involved in a call will become the Anchor MSC Server for this call during and after 
handover, and will remain in the call until the call is released. Every subsequent handover (Intra and Inter) will 
be controlled by this MSC Server. 

The first CS-MGW involved in a call will become the Anchor CS-MGW for this call during and after handover , 
and will remain in the call until the call is released. The Nc interface is anchored in the CS-MGW, the 
correlation between CS-MGW to PSTN and the CS-MGW to RAN remain fixed until the call is released. 

4.2.2 A mode to lu mode handover for CS services 

For A mode to lu mode inter-system Inter-MSC Hand-Over (GSM to UMTS) the MAP E interface transporting 
BSSMAP messages shall be used. As a network option, in the case of intra-PLMN inter-system handover from A mode 
to lu mode, the handover between two MSC-areas may be executed as 

intra-MSC handover, if the serving BSS is connected to the Anchor MSC; or 

subsequent intra-MSC handover or subsequent inter-MSC handover back to the Anchor MSC Server, if the 
serving BSS is connected to an MSC-B. The decision between these two alternatives is implementation and 
network configuration dependent. 

The procedure will be performed by utilising a direct SCCP connection between the target RNC located in the target 
MSC-area and the Anchor MSC or MSC-B, respectively. 

4.2.3 General principles for use of CS-MGW resources 

The following principles for use of CS-MGW resources apply: 

1. it shall not be necessary to have the CS-MGW co-located with the MSC Server; 

2. the CS-MGW resources need not be associated with any particular MSC Server (see note 1); 

3. it shall be possible for any MSC Server to request resources of any CS-MGW in the network (see note 1); 

4. it shall be possible for an RNC to connect to the CS-MGW indicated by the MSC server; 

Note 1 : For points 2 and 3 above, issues related to O&M procedures such as where notification of restart of a CS-MGW 
should be sent to, need to be considered. Extensions to H.248 may be required. 

The specification of the Bearer Independent CS CN which uses the CS-MGW is in TS 23.205 [14]. 
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4.2.4 Transcoder location 

The trancoders are located in the core network. They may be located in the CS-MGW at the border to the RAN (i.e the 
CS-MGW at the lu interface) or at the CS-MGW at the edge of the core network (e.g. at the edge towards the 
PSTN/ISDN) [13]. 

4.3 Packet Switched (PS) core network domain 

The requirements for the PS domain are in 23.060[2]. 

4.4 IP Multimedia subsystem (IMS) 

The requirements for the IMS are in 23.228[1 1] 

4.5 Cross Core Network Domain Requirements 

The specifications shall support the option of IP transport for the MAP and CAP based interfaces 

4.6 UTRAN 

The requirements for the UTRAN are in the 25-series. An overview can be found in 3GPP TS 25.401 [18]. 

4.7 GERAN 

The requirements for the GERAN are in 3GPP TS 43.051 [12] 



IP addressing 



5.1 IP version issues 

The UMTS/GSM architecture shall support IPv4 / IPv6 based on the statements below. 

IP transport between network elements of the IP Connectivity services (between RNC, SGSN and GGSN) and IP 
transport for the CS Domain: both IPv4 and IPv6 are options for IP Connectivity 

IM CN subsystem elements (UE to CSCF and the other elements e.g. MRF): 

The architecture shall make optimum use of IPv6. 

3GPP specifications design the IM CN subsystem elements and interfaces to exclusively support IPv6. 
However, early IMS implementations and deployments may use IPv4; if IPv4 is used, the guidelines and 
recommendations in TR 23.981 [24] should be followed. 

3GPP specifications design the UE to exclusively support IPv6 for the connection to the IM CN subsystem. 
The UE shall support IPv6 for the connection to the IM CN subsystem. However, UEs may in addition 
support IPv4 which allows for the connection to early IM CN subsystem implementations that use IPv4 only; 
in this case the guidelines and recommendations in TR 23.981 [24] should be followed. 

Access to existing data services (Intranet, Internet,. . .): 

The UE can access IPv4 and IPv6 based services. 
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5.2 Interoperability between IPv4 and IPv6 networks 

Since the UE can access both IPv4 and IPv6 based services, situations may arise where interworking is needed to 
interoperate with IPv4 and IPv6 networks. This section describes three different interworking scenarios: UE is IPv4 and 
IPv6 capable, IPv6 only UE, and IPv6 UE connected via IPv4 network to an IPv6 device. These scenarios are examples 
of IPv6 and IPv4 interworking. The scenarios presented below only considered cases of a Transition Gateway (TrGW) 
for generic services and specialist services may require additional functionally at the application level. 

5.2.1 IPv4/IPv6 Mobile connecting to IPv4 and IPv6 networks 

An installation where the UE has both IPv4 and IPv6 stacks is shown in Figure 5-1. As depicted, the terminal connects 
to the IPv4 device directly using an IPv4 PDP Context. Hence, the UE appears to be a standard IPv4 node to the 
external IPv4 network. This scenario does not need any specific transition support from the network. However, it 
requires both versions of IP at the UE. The GGSN in this scenario may be different for the IPv6 and the IPv4 
connections. 



IPv6 
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Figure 5-1 : UE with IPv4 and IPv6 capability connecting to IPv4 and IPv6 networks 

5.2.2 IPv6 only Mobile connecting to IPv4 network 




Figure 5-2 IPv6 only mobile connecting to IPv4 data services 

Figure 5-2 shows an IPv6 only terminal connected to an IPv4 device. The UE us using an IPv6 PDP Context for access 
to a Transition Gateway (TrGW) that translates the IPv6 packets to IPv4 and vice versa. The TrGW may be 
implemented as a Network Address Translation - Protocol Translation (NAT-PT) [16] to convert IPv6 traffic coming 
from the UE to IPv4 traffic and vice versa. 
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NAT-PT is a combination of NAT-like address translation and IP header conversion as described in [16]. NAT-PT uses 
a pool of IPv4 addresses for assignment to IPv6 nodes on a dynamic basis as sessions are initiated across v4-v6 
boundaries. NAT-PT binds addresses in the v6 network with addresses in the v4 network to provide transparent routing 
of packets traversing address realms. This requires no changes to end nodes and IP packet routing is completely 
transparent to them. It does, however, require NAT-PT to track the sessions it supports and mandates that inbound and 
outbound packets pertaining to a session traverse the same NAT-PT device. 

5.2.3 IPv6 Mobile connected to an IPv6 Device via an IPv4 network 



UE 

IFV6 


X" 


^ 








^ 


( 


RNC 




SGSN 




GGSN 





Figure 5-3 IPv6 mobile connected to an IPv6 device via an IPv4 network 

Figure 5-3 shows a case where an IPv4 network lies between two IPv6 domains. The IPv6 domains can be 
interconnected using IETF standard mechanisms such as automatic or configured tunneling of IPv6 over IPv4 [17]. 

5.3 Address management 

The UMTS network may be implemented as a number logically separate IP networks which contain different parts of 
the overall system. In this discussion each of these elements is referred to as an "IP Addressing Domain". Within an "IP 
Addressing Domain" it is required that the nodes within the domain are part of a consistent non-overlapping IP-address 
space. It is also required that IP packets may be routed from any node in the domain to any other node in the domain 
using conventional IP routing. In a real implementation an IP Addressing Domain may be a physically separate IP 
network or an IP VPN. 

IP Addressing Domains may be interconnected at various points. At these points of interconnect gateways, firewalls or 
NATs may be present. It is not guaranteed that IP packets from one IP Addressing Domain can be directly routed to any 
interconnected IP Addressing Domain. Rather inter-Domain traffic may be handled via firewalls or tunnels. This 
implies that different IP Addressing Domains can have different (and possibly overlapping) address spaces. 

Figure 5-4 below shows an example of the IP Addressing Domains involved in PS-domain and IP-subsystem services. 
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Traffic tunneled 
over GPRS 

Gi Implemented 

on VPN or dedicated resources 

for each instance 

Figure 5-4 - IP Addressing Domains Involved In PS-Domain and IM Services 

Though UMTS permits the possibiUty of using different IP Addressing Domains as shown above it is possible that 
several different IP Addressing Domains fall under a common co-operative management regime. In this case the 
different IP Addressing Domains may be implemented as a single administrative domain at the operator's discretion, 
thus using a common IP-address space. 

A UE accessing services in either an IM subsystem, the Internet, or an external Intranet, or a combination of these 
service domains within the same IP network, requires an IP address that is part of the target network's IP Addressing 
Domain. For each of these IP networks, the IP address is linked to a specific PDP context, or set of PDP contexts 
sharing this IP address via a single APN. 

When the UE establishes the PDP context to access an IP network, it may use an existing PDP context if it has an active 
context with a compatible IP addressing domain and quality of service profile. 



5.4 IP addressing and routing for access to IIVI -subsystem 
services 

This section deals with a UE accessing IM CN subsystem services via UMTS. 

A UE accessing IM CN Subsystem services requires an IP address that is logically part of the IM CN subsystem IP 
Addressing Domain. This is established using an appropriate PDP-context. It is possible to connect to a GGSN either in 
the VPLMN or the HPLMN. For routing efficiency this context may benefit from being connected though a GGSN in 
the visited network. The connection between the UE and the IM CN subsystem (where the GGSN is either in the Home 
or the Visited network) is shown below: 
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Virtual presence of UE 

in visited network IIVI subsystem 

(UE's IP-address is here) 




Figure 5-5 UE Accessing IIVI Subsystem Services with GGSN in the visited network 



Home Network 



Virtual presence of UE 

in Home network IM subsystem 
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Figure 5-5a UE Accessing IM CN subsystem Services with GGSN in the Home network 

5.5 Simultaneous access to multiple services 

A UE can have multiple services active simultaneously. When the services are part of different IP addressing domains, 
separate PDP contexts and IP addresses are required. The UE shall support multiple IP addresses when simultaneous 
PDP contexts are activated that require separate IP addresses for different addressing domains. 

Figure 5-6 shows an example of a connection between a UE and an Internet/Intranet service that is not available in the 
Visited Network with a simultaneous connection to the Visited Network's IM Subsystem. In this example, there may be 
two IPv6 addresses allocated, or one IPv4 address allocated for internet/Intranet access and oneIPv6 address for IM 

subsystem access.. 
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PDP Context 



Figure 5-6 UE Accessing IHome Internet/Intranet Services and Visited Networl< IIU! 



5.6 UE support of IPv6 



The set of IPv6 functionality a 3GPP UE will require is dependent on the services (IMS, Packet Streaming etc.) it will 
use. 

As a minimum, a 3GPP UE shall comply with the Basic IP group of specifications as defined in RFC3316 [21]. This 
IPv6 functionality is sufficient to provide compatibility towards IPv6 entities external to 3GPP. 

A 3GPP UE shall follow the recommendations for the IP Security set of functions in RPC3316 [21] when a specific 
service requires such functions. 

According to the procedures defined in TS 23.060 [2], when a UE is assigned an IPv6 prefix, it can change the global 
IPv6 address it is currently using via the mechanism defined in RFC 3041 [17a], or similar means, without updating the 
PS domain. Any application that requires full IP address knowledge shall provide a mechanism to get the latest IPv6 
address when the IPv6 address in the UE has been changed. An example of such means is defined in TS 23.228 [11]. 

Note: RFC3316 [21] does not make any recommendations on preferred transition and interoperability 
mechanisms between IPv4 and IPv6. 



Mobility management 



6.1 



Introduction 



From a logical point of view, the CN encompasses two domains, a CS domain and a PS domain. The RAN can be 
connected either to both these CN domains or to one of the CN domains. 

A single RRC connection (between RAN and UE) shall carry all user plane and signalling flows to/from a UE. This is 
regardless of where in the CN they originate/terminate. 

The 3GPP specifications for UMTS and GSM in lu mode shall support compatibility with GSM network in A/Gb mode 
from the point of view of roaming and handover. For the LM/MM functionality point of view this implies among other 
things the following: 

a) IMSI shall be used as the common user identity in the two CN domains; 

b) common MAP signalling is applied to networks supporting either lu or A/Gb mode or both. 

c) radio network parameters and radio resource management should be isolated in the RAN. 
The LM/MM techniques used should minimise radio resource usage of the RAN. 
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6.2 Location management and mobility management concept 
overview 

6.2.1 Non-combined procedures 

From a logical point of view, the CN consists of two domains, a CS domain and a PS domain or one of these domains. 

Each domain has its own service state machine. An UE, that is supporting both CS services and PS services, has a CS 
service state machine and a PS service state machine. The two peers of the service state machine are working 
independently to each other, although associated to the same UE. The UE-CN signalling aims to keep the peer entities 
synchronised. 

As an introduction, figure 6.1 and figure 6.2 give an overview of the UE registration and connection principles when the 
CN consists of two separate PS and CS service nodes or one combined CS and PS service node. 



Common subscription 
data base 



Two CN service domains 




T — Two lu signalling connections 
T ("two RANAP instances") 



RAN with) 
distribution 
functionality 



^ 



-L One RRC connection 



CS stated : PS state 

"Tje 



Figure 6.1 : Overview of the UE registration and connection principles 
for the separate CN architecture case 

In the separate CN architecture case, the CN consists of both a CS domain with evolved MSCA^LR, 3G_MSC/VLR, as 
the main serving node and an PS domain with evolved SGSN/GGSN, 3G_SGSN and 3G GGSN, as the main serving 
nodes. 
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Figure 6.2: Overview of thie UE registration and connection principles 
for the integrated CN architecture case 

In the integrated CN architecture case, the CN consists of both a CS domain and an PS domain with an combined MSC 
and SGSN as the main serving node. 

The main PS service states are PS-DETACHED, PS-IDLE and PS-CONNECTED. The main CS service states are 
CS-DETACHED, CS-IDLE and CS-CONNECTED. For the respective domain there are specific related MM system 
information controlling the MM functionality of the UE. 

The aim of the RAN is to offer one unified set of radio bearers which can be used for bursty packet traffic and for 
traditional telephony traffic. Therefore, only one logical control channel structure is used for all kind of traffic. The 
radio resource handling is RAN internal functionality and the CN does not define the type of radio resource allocated. 

The Radio Resource Control (RRC) has two modes, RRC Connected mode and RRC Idle mode. The RRC mode 
describes which identity is used to identify the UE. In RRC Idle mode the UE is identified by a CN associated identity. 
In RRC Connected mode the UE is assigned a Radio Network Temporary Identity to be used as UE identity on common 
transport channels. When the UE is allocated dedicated transport channels, it uses the inherent addressing provided by 
these transport channels. 



In PS-CONNECTED state the UE is in RRC Connected mode, 
mode. 



In CS-CONNECTED state the UE is in RRC Connected 



For the mobility functionality, four different area concepts are used. Location Areas (LAs) and Routing Areas (RAs) are 
used in the CN. UTRAN Registration Areas and Cell Areas are used in the RAN. LAs are related to CS services. RAs 
are related to PS services. 

One LA is handled by one CN node. For an UE that is registered in a LA, this implies that the UE is registered in the 
specific CN node handling this specific LA. One RA is handled by one CN node. For an UE that is registered in a RA, 
this implies that the UE is registered in the specific CN node handling this specific RA. LA is used by the 
3G_MSC/VLR for paging the UE. RA is used by the 3G_SGSN for paging the UE. UTRAN Registration Areas and 
Cell Areas are only visible in the RAN and used in RRC-Connected mode. 

For the relations between LA and RA is described in clause 4.3.2. 

In RRC Idle mode it is the broadcast MM system information (e.g. information about the present LA and present RA) 
that determines when the UE initiates a location registration procedure towards the CN. An UE crossing an LA border. 
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in state CS-IDLE and RRC Idle mode, shall initiate LA update towards the CN. An UE crossing an RA border, in state 
PS-IDLE and RRC Idle mode, shall initiate RA update towards the CN. 

In RRC Connected mode, the UE receives the MM system information on the established RRC connection. (I.e. the 
broadcast MM system information is not used by the UE in the RRC connected mode.) An UE receiving information 
indicating a new LA,in state CS-IDLE and RRC Connected mode, shall initiate LA update towards the CN. An UE 
receiving information indicating a new RA, in state PS-IDLE and RRC Connected mode, shall initiate RA update 
towards the CN. An UE in state CS-CONNECTED and RRC Connected mode, shall not initiate LA update towards the 
CN. An UE in state PS- CONNECTED and RRC Connected mode, shall not initiate RA update towards the CN. 

In CS-DET ACHED mode the UE shall not initiate any LA update and this independent of the RRC mode. In PS- 
DETACHED mode the UE shall not initiate any RA update and this independent of the RRC mode. 

In additional to normal location registration when changing registration area, the UE may (network options) perform CS 
periodic registration when in CS-IDLE state and PS periodic registration when in PS-IDLE state. The respective 
periodic registration may be on/off on LA respective RA level. 

On the MM level, IMSI and CS related TMSI are used as UE identities in the CS domain, and IMSI and PS related 
TMSI are used as UE identities in the PS domain. The IMSI is the common UE identity for the two CN domains (CS 
and PS). 

A signalling connection between the UE and the CN refers to a logical connection consisting of an RRC connection 
between UE and RAN and an lu signalling connection ("one RANAP instance") between the RAN and the CN node. 
The CS domain related signalling and PS domain related signalling uses one common RRC connection and two lu 
signalling connections ("two RANAP instances"), i.e. one lu signalling connection for the CS domain and one lu 
signalling connection for the PS domain. 



6.2.2 Use of combined procedures 



The use of separated PS and CS mobility mechanisms within the UE and within the CN can lead to non-optimal usage 
of the radio resource (for example a UE in PS idle and CS idle state would perform both LA updates (for the CS 
mechanism) and RA updates (for PS mechanisms)). 

To offer flexibility in the provision of MM , combined mechanisms can be used for LM purposes as well as for 
attach/detach status purposes. 

A UE can perform combined update mechanisms. A CN should allow combined update operations (operator option). 
UEs should support the use of both combined and separate mechanisms. 

NOTE: The support of this feature by all UEs will also ease evolution of MM in the future. 

The RAN does not co-ordinate MM procedures that are logically between the CN and the MS. This includes: LM, 
authentication, temporary identity management and equipment identity check. 

6.3 Description of the location management and mobility 
management concept - area concepts 

6.3.1 Introduction 

For the mobility functionality five different area concepts are used. LA and RA in the CN as well as UTRAN 
Registration Area, GERAN Registration Area and Cell areas in the RAN. 

6.3.2 Location areas 

For CS services, the CN uses LA. LA is used e.g. at CN initiated paging related to CS services. A CS service related 
temporary identity, CS -TMSI, may be allocated to the UE. This temporary identity is then unique within a LA. 
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6.3.3 Routing areas 

For PS services, the CN uses RA. RA is used e.g. at CN initiated paging related to PS services. A PS service related 
temporary identity, PS-TMSI, may be allocated to the UE. This temporary identity is then unique within a RA. 

6.3.3a Support of lu and A/Gb mode of operation in GERAN Cells 



6.3.3a.i 



Overview 



A GERAN capable cell may belong to the same LA/RA for both modes of operation (figure 6.2a). In the case of a 
combined CN node supporting both lu and A/Gb mode MSs, a single LA/RA identity for MSs in either mode shall be 
broadcasted in the cell since the same LAI and RAI will be used in both modes of operation. 




Figure 6.2a: Combined iu/A/Gb Cell with Combined CN nodes 

It is also possible for GERAN capable cell to support both A/Gb and lu mode of operation without any restriction on 
combined CN nodes (figure 6.2b). In order to support this GERANcapable cells need to support the possibility to 
broadcast both LA/RA identities for MSs in lu mode and for MSs in A/Gb mode. The existing LAI/RAI will be used for 
mobiles operating in A/Gb mode while the LAI/RAI for lu mode will be used for mobiles operating in lu mode. The 
reason for this is that the LA and RA cannot in this case overlap the both CNs. 
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Figure 6.2b: Combined A/Gb/iu Cell with Separate CN 

6.3.3a.2 Interface selection in GERAN Cells 

The MS shall be able to derive the mode supported in cell from the information broadcasted. 

The support of different modes of operation in the MS shall be indicated in the MS Classmark and/or the MS Radio 
Access Capabilities. 

6.3.3a.2.1 Basic principles for MS controlled Cell/Mode selection/re-selection 

The procedures for MS controlled cell selection/re-selection are done according to UMTS/GSM principles and 
procedures outlined in TS 25.304 and 45.008. This means that a GERAN cell will be selected regardless which mode it 
supports. The cell selection is based on radio criteria and not service. 

If a GERAN cell is selected and it is both lu and A/Gb capable, an lu and A/Gb capable mobile station shall select lu 
mode of operation by default. 

NOTE: The above text outlines the default mechanism of mode of operation selection and does not prohibit the 
introduction of a more flexible solution, which avoids unecessary mode of operation changes, at a later 

stage 

6.3.3a.2.2 Basic principles for network controlled Mode selection/re-selection 

The procedures for network-controlled cell selection/re-selection are done according to UMTS/GSM principles. When a 
cell/mode change is ordered by the network, the mode of operation to apply will be indicated by the network. 

6.3.4 RAN internal areas 

RAN internal areas are used when the terminal is in RRC-Connected mode (see clause 6.7). The areas are used at e.g. 
RAN initiated paging. RAN internal area updating is a radio network procedure and the RAN internal area structure 
should not be visible outside the RAN. In RRC connected mode, the UE position is known on cell level or on 
URA/GRA level. RNTI is used as a temporary UE identifier used within the RAN and allocated at RRC connection 
establishment. 

6.3.5 Relationship between the different areas 

The following area relations exist (see figure 6.3): 
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• there need not be any relation between URA/GRA and LA respectively between URA/GRA and RA. The URA 
concept is defined in 3GPP TS 25.331 [5] and the GRA concept is defined in 3GPP TS 43.051 [12]; 

• one RA consists of a number of cells belonging to RNCs that are connected to the same CN node; 

• one LA consists of a number of cells belonging to RNCs that are connected to the same CN node; 

• one RA is handled by only one CN serving node, i.e. one combined MSC+SGSN or one 3G_SGSN; 

• one LA is handled by only one CN serving node, i.e. one combined MSC + SGSN or one 3G_MSC/VLR. 
The GSM defined relations between LA and RA applies i.e. the following relations between LA and RA are possible: 

RA and LA is equal; 

one RA is a subset of one, and only one, LA, meaning that a RA do not span more than one LA. 

The mapping between one LA and RNCs is handled within the MSC/VLR owning this LA. The mapping between one 
RA and RNCs is handled within the SGSN owning this RA. The mapping between LA and cells respective between RA 
and cells is handled within RNC. 





URA/ 
GRA 



^^ Cell 



->RA(s) handled by one 
-► LA(s) handled by one 



>LA(s) and RA(s) handled by one 

The URA/GRAs does not need to have a 
one to one relation to the RNC/BSS or 
any CN nodes like the LA/RA. 



Figure 6.3: Relationship between different areas 

6.3.6 Hierarchical tracking concept 

A packet UE (in RRC connected mode) is tracked at the cell level by RNC during an active connection. 

A packet UE (in RRC connected mode) is tracked at the URA level by RNC when no data are actively transfer, and the 
probability of data transfer is quite high. 

A packet UE (in PS-Idle state) is tracked at the RA level by SGSN when no data is actively transferred and the 
probability of data transfer is quite low. The network operator can optimise paging and updating load by controlling the 
size of the different areas and the probability of data transfer (controlled by the RRC_connection_release timer). For 
example, one operator can decide that URA/GRA are small, and that RRC connection are released after a relatively 
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short time of inactivity, so that most attached packet UE are tracked in the RA level (optimum for packet UE mainly 
using client-server type of service). 

Another operator can decide that URA/GRA are large, and that RRC connection are released only if RRC connection is 
lost, so that most attached packet UE are tracked at the URA level. 

The procedure for the releasing of the RRC connection can be found in 3GPP TS 23.060 [2] under the lu release 
procedure. The URA update procedures can be found in 3GPP TS 25.331 [5] and GRA update procedures can be found 
in3GPPTS43.051[12]. 

6.4 Relationship between IVIIVI and SIVI states for an UE 

When a UE is attached to PS service, it may have, but need not have, some PDP context established. 

If the UE has no PDP context established (SM-Inactive), no radio access bearer are established for PS service. The UE 
is in RRC connected mode, only if the state is CS-CONNECTED state or PS-CONNECTED state (i.e. only a PS 
signaling connection is established). 

If the UE has at least one PDP context established (SM- Active), the UE can be in PS-CONNECTED state or in PS- 
IDLE state. 

NOTE: The PDP context status is not modified by the release of the RRC connection, except if the release of the 
connection is due to an RRC failure which do not permit to maintain the negotiated QoS (e.g. a real time 
connection). 

6.5 Requirement in case of temporarily loss of coverage of 
packet UE 

A packet attached UE using non-real time bearer shall not lose its PDP context in case of temporarily loss of coverage. 
A UE specific Mobile Reachable Timer monitors how long PDP context(s) are kept after a UE has lost coverage. 

6.6 IVIIVI functionality in different UE service states 

CS service states and related MM functionality: 

CS-DETACHED: The UE is not reachable by the network for CS services. The UE does not initiate LA updates 
at LA changes and no periodic CS service updates; 

CS-IDLE: The UE is reachable by paging for CS services. The UE initiates LA updates at LA changes. The UE 
may initiate periodic CS service updates and this depends on the CS periodic update state of the present LA; 

CS-CONNECTED: The UE has a signalling connection for CS services established between the UE and the CN. 
The UE does not initiate LA update (even not when the present LA changes) and no periodic CS service updates. 

PS service states and related MM functionality: 

PS-DETACHED: The UE is not reachable by the network for PS services. The UE does not initiate RA updates 
at RA changes and no periodic PS service updates; 

PS-IDLE: The UE is reachable by paging for PS services. The UE initiates RA updates at RA changes. The UE 
may initiate periodic PS service updates and this depends on the PS periodic update state of the present RA; 

PS-CONNECTED: The UE has a signalling connection for PS services established between the UE and the CN. 
The UE initiates RA update when RAI in MM system information changes. No periodic PS service updates. 

There can also be a NULL state. In the UE, this state corresponds to power off or possibly a "no SIM" condition. In the 
CN, the NULL state correspond to CS-DETACHED and PS-DETACHED. 

For each state transition there can be several events that triggers the transition. Some of them are described below. 
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NOTE: Some of these can coincide, e.g. moving from CS-IDLE to CS-DET ACHED and moving from PS-IDLE 
to PS-DETACHED. 

Moving from CS-IDLE to CS-CONNECTED: 

The state transition from CS-IDLE to CS-CONNECTED is performed when a signalling connection is established 
between UE and CN for CS services. In GSM this state transition is triggered by the message 
CM_SERVICE_REQUEST or PAGE_RESPONSE. 

Moving from CS-CONNECTED to CS-IDLE: 

The state transition from CS-CONNECTED to CS-IDLE is performed when the signalling connection for CS services is 
released, e.g. at call release and no other CS service is ongoing. A radio link failure can also trigger this state transition. 

Moving from CS-IDLE to CS-DETACHED: 

The transition from CS-IDLE to CS-DETACHED can be triggered by some action from the user of the UE but an 
expiring timer in the network could also trigger it. The UE is marked as CS_DET ACHED in the CN and then as a 
consequence no CS service establishment is possible. 

Moving from PS-IDLE to PS-CONNECTED: 

The state transition from PS-IDLE to PS-CONNECTED is performed when a signalling connection is established 
between UE and CN for PS services. 

Moving from PS-CONNECTED to PS-IDLE: 

The state transition from PS-CONNECTED to PS-IDLE is performed when the signalling connection for PS services is 
released, e.g. at release of a PS service, no other PS service is ongoing and at release of the RRC connection in case of 
very low level of activity. A radio link failure can also trigger this state transition. 

Moving from PS-IDLE to PS-DETACHED: 

The transition from PS-IDLE to PS-DETACHED can be triggered by some action from the user of the UE but an 
expiring timer in the network could also trigger it. The UE is marked as PS_DET ACHED in the CN and then as a 
consequence no PS service establishment is possible. 

6.7 The RRC state machine 

The RRC state machine is a description model of how the UE and the RAN co-operate regarding RRC functionality. 
The RRC state describes the state of the UE in the RAN. Here follows a brief description of the RRC state machine, for 
more information see TS 25.301 [6] and TS 25.303 [7]. 

NOTE: RRC idle mode and RRC connected mode refer to the UE idle mode and UE connected mode respectively 
in TS 25.301 [6] and TS 25.303 [7]. 

The RRC state machine exists as peer entities, one in the UE and one in RAN. Apart from transient situations and error 
cases they are synchronised. Figure 6.4 illustrates the main modes/states of the RRC state machine. 
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Figure 6.4: RRC modes, main RRC states and main mode/state transitions 

RRC-Idle_mode: 

In the Idle mode there is no connection established between UE and RAN. There is no signalling between RAN and the 
UE except for system information that is sent from RAN down link on a Broadcast channel to the UE. The UE can also 
receive paging messages with a CN identity on the PCH. There is no information on the UE stored in RAN in this state. 

RRC-Connected_mode: 

In the Connected mode the main states are Cell Connected state and URA connected state. In this mode there is one 
RNC that is acting as Serving RNC (SRNC), and an RRC connection is established between the UE and this SRNC. 

• When the UE position is known on cell level, the UE is in the cell connected state. When in cell connected state, 
the RRC connection mobility is handled by handover procedures. 

• When the UE position is known on URA level, the UE is in the URA connected state. The URA contains a set of 
cells. URA updating procedures provides the mobility functionality in this state. In URA connected state no 
dedicated radio resources are used. 

6.8 Relationship between CS and PS service states and RRC 
state for an UE 

During non-transient conditions the following relations are valid between service states and RRC modes for an UE: 

- when in either CS-CONNECTED state or PS-CONNECTED state, or in both CS-CONNECTED state and PS- 
CONNECTED state, then the UE is in RRC connected mode; 

- when in neither CS-CONNECTED state nor PS-CONNECTED state, then the UE is in RRC idle mode. 

Figure 6.5 and figure 6.6 illustrate two examples on the relations between the RRC states and CS/PS service states. 
These figures illustrate the separated CN case. 
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Figure 6.5: UE in CS-CONNECTED state and PS-IDLE state 
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Figure 6.6: UE in CS-IDLE state and PS-DETACHED state 



6.9 Service registration and location update 
6.9.1 Introduction 

Service registration (attach) in the respective CN domain is done initially (after UE being detached due to e.g. power 
off). When a registration area is changed a location update is performed. In addition, periodic registration can be 
performed. Here follows descriptions of when the respective CN registration area is changed. 

NOTE: It is not here defined which different registration procedures that are needed. 
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6.9.2 Location area update 



LA update is initiated by the UE to inform the CS domain of the CN that the UE has entered a new LA. In case the new 
LA is in an area served by another CN node, the LA update also triggers the registration of the subscriber in the new 
CN node and a location update for CS services towards the HLR. 

LA update is only initiated by the UE when the UE is in state CS-IDLE, and this independently of the PS state. If the 
UE is CS-IDLE but RRC connected, which means that the UE is in PS-CONNECTED state, LA update is initiated by 
the UE when it receives information indicating a new LA. 

6.9.3 Routing area update 

RA update is initiated by the UE to inform the PS domain of the CN that the UE has entered a new RA. In case the new 
RA is in an area served by another CN node, the RA update also triggers the registration of the subscriber in the new 
CN node and a location update for PS services towards the HLR. 

RA update is initiated by the UE when the UE is in state PS-IDLE, and this independently of the CS state. If the UE is 
PS-IDLE but RRC connected, which means that the UE is in CS-CONNECTED state, RA update is initiated by the UE 
when it receives information indicating a new RA. 

When the UE is in PS-CONNECTED state the UE initiates RA update when RAI in MM system information changes. 



6.9.4 Combined updates 



The GSM radio interface combined procedures and their support via the Gs interface is the starting point for the support 
of combined updates. 



6.10 Paging initiated by CN 



A CN node requests paging only for UE in CS-IDLE state or PS IDLE state. In the separate CN architecture, paging 
from a CN node is done independent of the service state of the UE in the other CN domain type. 

Paging is co-ordinated within the UTRAN. Details on how the co-ordination is achieved and the parameters to be 
provided by the CN are specified in 3GPP TS 25.413 [9]. The procedures required between the UTRAN and UE are in 
3GPPTS 25.331 [5]. 

In case of a single CN element, paging may be co-ordinated at the CN. 

6.1 1 Signalling connection establishment 

A signalling connection between the UE and a CN node refers here to a logical connection consisting of an RRC 
connection between UE and the RAN and an lu signalling connection between the RAN and the CN node. The 
signalling connection is used for transfer of higher layer (MM, CM) information between the UE and the CN node. 

At a CM service request to one of the CN domain types and when no such connection exists towards the applicable CN 
domain type, the UE shall request establishment of a new signalling connection. 

If no RRC connection exists, this is established in conjugation with (before) the transfer of the signalling establishment 
request. At the RRC connection establishment, an UE context is built up in the SRNC. 

If an RRC connection is already established, the UE shall send the signalling establishment request using that RRC 
connection. 

At reception of the signalling establishment request, the SRNC will establish an lu connection towards the CN node 
indicated by the CN service domain type received from UE. 
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6. 11 a CS Domain Signalling Requirements (in particular relating 

to handover) 

Correct operation of the Call Control, Mobility Management and Call Independent Supplementary Service protocols 
requires that downlink messages from the MSC shall be delivered in the correct order and shall not be lost, duplicated 
or delivered in error. 

The RAN and lu/A interfaces shall provide this functionality in all cases except for when the lu/A interface SCCP 
connection is being changed, eg at SRNS relocation or inter-BSC (external) handover. 

When the SCCP connection is being changed, the MSC shall buffer downlink CC, MM and CISS messages. 
Specifically, the MSC shall buffer messages from these protocols after transmission of a (BSSMAP) Handover 
Command or RANAP-Relocation Command message and until receipt of a Handover Complete, Relocation Complete, 
Handover Failure or Relocation Cancel message. 

In the uplink, the UE is responsible for delivering the CS domain messages across the radio interface. Once the message 
has been received by part of the network, it is the network's responsibility to deliver the message to the MSC. This can 
result in duplicate message delivery to the CN. The RAN shall ensure that the protocol used between UE and RAN 
permits any duplicate messages that are delivered to the CN, to be correctly discarded by N(SD) mechanism specified in 
3GPP TS 24.007 [22] for the uplink CC, MM and CISS messages. 

6.12 Relations between SRNS relocation and location 
registration 

This clause clarifies the need for separate handling of MM registration area (LA and RA) information in RRC idle mode 
respective in RRC connected mode. The following example illustrates relations between SRNC relocation, registration 
area (LA/RA) change and LA/RA updates. As shown in the example, this is equally applicable for a combined MSC + 
SGSN as well as the 3G-MSC/VLR and 3G-SGSN. 

NOTE 1 : The example is based on the assumptions that one RNC can set up lu connections to only one 

3G_MSC/VLR (or combined MSC+SGSN) and only one 3G_SGSN (or combined MSC+ SGSN), and 
that the CN node is configured to only send page to the RNC(s) that is controlling cells within the 
relevant LA/RA. 

Preconditions (see figure 6.7): 

- LAI is handled by 3G_MSC/VLR1 and LA2 is handled by 3G_MSC/VLR2 ; 

- RAl is handled by 3G_SGSN1 and RA2 is handled by 3G_SGSN2 ; 

- UE is registered in LAI in 3G_MSCA^LR1 and in RAl in 3G_SGSN1; 

- the UE is in PS-CONNECTED state and a signalling connection exists between UE and 3G_SGSN1; 
the UE is in CS-IDLE state and no signalling connection exists between UE and 3G_MSC/VLR1; 

- RNCl is acting as SRNC and RNC2 is acting as DRNC; 

UE is in RRC cell connected state and with dedicated channels established to cells within both RNCl and RNC2. 
UE does not listening to the PCH; 

the registration area information sent to the UE indicates LAI and RAl. 

The UE can always (at least in normal working states) identify the present available registration area (LA respective 
RA) associated with the respective CN domain. The determination of the present area differs depending on the state of 
the UE. For UE in RRC idle mode (UE with no ongoing communication with the network) it is the cell selection 
mechanism in the UE that is used. For UE in RRC connected mode it is the RAN that determines the area (although a 
change can implicit be initiated by the UE). 
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Figure 6.7: Illustration of the preconditions in the described example 

In figure 6.7 MSC stands for 3G_MSC/VLR and SGSN for 3G_SGSN. 

The UE moves now further towards the right, leaving the coverage area of cells controlled by RNCl, and resulting in 
that the UE has dedicated channel(s) established to cell(s) within only RNC2. This can result in the following sequence 
of events: 

- the SRNC (RNCl) can decide to perform an SRNC relocation resulting in that the RNC2 becomes SRNC. In this 
example, the change of SRNC also implies a change of SGSN with an update of the UE location registration for 
the PS domain; 

after this SRNC relocation or combined with this procedure, the MM registration area information sent to the UE 
is changed and indicates now LA2 and RA2; 

NOTE 2: The MM registration area information need not be sent for every SRNS relocation, nor does it preclude 
MM registration area information being sent in other occasions. 

the UE initiates a LA update, which results in a registration change from LAI in 3G_MSC/VLR1 to LA2 in 
3G_MSC/VLR2 and results in changed MM registration information. 

NOTE 3: The area information can not be changed to indicate LA2 unless SRNC relocation has been performed, 

because the LA update signalling is sent from the UE, by using the established RRC connection to SRNC, 
and then to the 3G_MSC/VLR to which the SRNC belongs. 

6.13 Requirements on identifiers for UIVITS and GSiVI 

la) The format of the UMTS Location Area Identifier and UMTS TMSI shall not prevent a dual mode GSM-UMTS 
mobile which was last location updated over the GSM radio interface (i.e. has a GSM LAI and GSM TMSI), 
from performing a location update (or other signalling) over the UMTS radio interface to a UMTS MSC. 

lb) The format of the UMTS Location Area Identifier and UMTS TMSI shall not prevent a dual mode GSM-UMTS 
mobile which was last location updated over the UMTS radio interface (i.e. has a UMTS LAI and UMTS TMSI), 
from performing a location update (or other signalling) over the GSM radio interface to a GSM MSC. 

lc)The format of the UMTS Routing Area Identifier and UMTS P-TMSI shall not prevent a dual mode 

GSM-UMTS mobile which was last routing area updated over the GSM radio interface (i.e. has a GSM RAI and 
GSM P-TMSI), from performing a routing area update (or other signalling) over the UMTS radio interface to a 
UMTS SGSN. 

Id) The format of the UMTS Routing Area Identifier and UMTS P-TMSI shall not prevent a dual mode 

GSM-UMTS mobile which was last routing area updated over the UMTS radio interface (i.e. has a UMTS RAI 
and UMTS P-TMSI), from performing a routing area update (or other signalling) over the GSM radio interface 
to a GSM SGSN. 

2) The standard shall support means by which an operator can configure GSM and UMTS cells to be members of 
the same registration area (i.e. the mobile can receive paging from whichever cell it is camped on and does not 
need to location update (or routing update) just because the mobile has changed from a UMTS to a GSM cell). 
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3a) The standard shall support means by which an operator can allocate GSM and UMTS LAIs which enable GSM 
MSCs to be able to contact UMTS MSCs and vice versa. 

3b) The standard shall support means by which an operator can allocate GSM and UMTS RAIs which enable GSM 
SGSNs to be able to contact UMTS SGSNs and vice versa. 

4) The standard shall support means by which an operator can ensure that the IMSI does not need to be sent 
over the radio interface when the mobile station moves from a GSM cell to a UMTS cell (and vice-versa). 

5) The standard shall support means by which an operator can ensure that the IMSI does not need to be sent 
over the radio interface when a USIM is moved from a UMTS mobile station to a GSM mobile station (and 
vice-versa). 

6) The standard need not support means by which an operator can ensure that the IMSI is not sent over the radio 
interface when a GSM SIM is moved from a GSM mobile station to a UMTS mobile station (and vice-versa). 



6.14 Use of MM system information 



In each cell the network broadcasts MM system information on the broadcast channel. . The "current MM system 
information" is used by the MM functionality in the UE respecting the rules for the UE service state of the respective 
MM state machine, see clause 6.6. The "current MM system information" is identified as follows: 

In RRC idle mode, when the UE camps on one cell, it receives all MM system information valid for this cell on 
the broadcast channel of the cell. The received MM system information is then the "current MM system 
information"; 

In RRC connected mode, the SRNS shall control the current MM system information valid for the UE. e.g. at 
SRNS relocation, the new SRNS may send applicable MM system information to the UE. The established RRC 
connection shall be used for transferring any new MM system information to the UE. The UE shall use any new 
MM system information received from the SRNC on the established RRC connection as the "current MM system 
information"; 

NOTE: The MM system information need not necessarily be sent for every SRNSs relocation, nor does it prelude 
MM system information being sent on other occasions. 

At the RRC connection establishment, the UE uses the broadcasted MM system information of the cell where the 
establishment is made as the "current MM system information"; 

When the UE leaves the RRC connected mode and enters RRC idle mode, the UE uses the broadcasted MM 
system information of the chosen cell, which is determined by the UE idle mode cell selection/re-selection 
process that is then performed, as the "current MM system information"; 

6.15 Signalling procedures 
6.15.1 Idle mode procedures 

The signalling procedures shown in the following clauses do not represent the complete set of possibilities, nor do they 
mandate this kind of operation. This document specifies a set of elementary procedures for each interface, which can be 
combined in different ways in an implementation. Therefore these sequences are merely examples of a typical 
implementation. By default the combined procedures as defined in TS 23.060 [ 2] are also applicable when using Gs. 

The list of parameters should be regarded as examples of possible information carried by the messages and not as a 
complete list. 

6.1 5.1 .1 Location Area update 

Figure 6.8 shows location registration when changing LA including change of 3G-MSC/VLR and when the UE is in 
MM idle state towards the 3G_MSC/VLR. 
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The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection 
can have been established beforehand due to ongoing interwork between UE and 3G-SGSN or be established only for 
this location registration procedure towards the 3G_MSC/VLR. 

For each indicated MM message sent in this case to/from UE, the CN discriminator indicates 3G_MSC/VLR. 
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Figure 6.8: Interface information transfer for location update when changing VLR area 

1. The RRC connection is established, if not already done. The UE sends the initial message LA Update Request 
(old TMSI, old LAI, etc.) to the new 3G_MSC/VLR. The old TMSI and LAI are those that were assigned to the 
UE. The SRNS transfers the message to the 3G_MSC/VLR 

NOTE: The sending of this message to 3G_MSC/VLR also implies establishment of a signalling connection 
between SRNS and 3G_MSC/VLR for the concerned UE. 

The RAN shall add the RAC and the LAC of the cell where the message was received before passing the 
message to the MSC. 

2. The new 3G_MSC/VLR sends an Send Identification Request (old TMSI) to the old 3G_MSCAALR to get the 
IMSI for the UE. (The old LAI received from UE is used to derive the old 3G_MSC/VLR identity/address.) The 
old 3G_MSCA^LR responds with Send Identification Ack. (IMSI and Authentication triplets). 

3. Security functions may be executed. 

4. The new 3G_MSC/VLR inform the HLR of the change of 3G_MSCA'LR by sending Update Location (IMSI, 
MSC address, VLR number) to the HLR. 

5. The HLR cancels the context in the old 3G_MSC/VLR by sending Cancel Location (IMSI). The old 
3G_MSC/VLR removes the context and acknowledges with Cancel Location Ack. 
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6. The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_MSC/VLR. The new 
3G_MSC/VLR acknowledges with Insert Subscriber Data Ack. 

7. The HLR acknowledges the Update Location by sending Update Location Ack. to the new 3G_MSC/VLR. 

8. The new 3G_MSC/VLR validates the UE presence in the new LA. If due to regional, national or international 
restrictions the UE is not allowed to attach in the LA or subscription checking fails, then the new 3G_MSC/VLR 
rejects the LA update with an appropriate cause. If all checks are successful, then the new 3G_MSC/VLR 
responds to the UE with LA Update Accept (new TMSI, new LAI). 

9. The UE acknowledges the new TMSI with a TMSI reallocation Complete. (TMSI can optionally be reallocated 
with the TMSI reallocation procedure). 

10. When the location registration procedure is finished, the 3G_MSC/VLR can release the signalling connection 
towards the SRNS for the concerned UE. The SRNS shall then release the RRC connection if there is no 
signalling connection between 3G_SGSN and SRNS for the UE. 

6.1 5.1 .2 Routing Area Update 

The routing area update procedure is detailed in 3GPP TS 23.060[2]. 

6.1 5.1 .3 Periodic registration towards both CN nodes without use of Gs 

Periodic registration for the CS domain is specified in 3GPP TS 23.012 [3]. Periodic registration for the PS domain is 
covered in 3GPP TS 23.060 [2]. In the case of a combined node, this procedure does not apply. 

6.1 5.1 .4 Periodic registration with use of Gs or combined MSG+SGSN node 

Periodic registration for the PS domain is covered in 3GPP TS 23.060 [2]. Only RA Update req. registration is required 
from the UE to the 3G-3G-SGSN. This procedure applies for a combined 3G-MSC/3G-SGSN. 

6.1 5.1 .5 UE initiated combined detach procedure when using Gs or combined 
MSC+SGSN node 

UE initiated Combined Detach Procedure when using Gs or combined MSC+SGSN node is specified in 3G 23.060 [2]. 
The UE specifies which form of detach is required, i.e., PS Detach only, CS Detach only or combined Detach. 

6.15.1.6 Forbidden LA/RA 

The CN (SGSN and MSCA^^LR) shall not send the COMMON Id message with SNA information to the UTRAN when 
the Attach Request, LA Update, or RA update are rejected. 

6.15.2 SRNS Relocation 

SRNS relocation is covered in 25.413 [9] and 3GPP TS 23.060 [2]. 
NOTE: Examples of RAN signalling are given in TR 25.931 [15]. 

6.16 RAN coordination 

The RAN coordinates the resource allocation of an UE attached to both PS and CS services. The UTRAN shall reject or 
downgrade a connection which cannot be granted, see 3GPP TS 23.060 [2]. The cause might be congestion on the radio 
interface, or the existence of other connections between this UE and the other CN. 

The RAN uses the IMSI to identify a UE. The IMSI is transferred from the CN to the RAN with the common ID 
procedure. When an lu connection is established, the CN shall perform the RANAP common ID procedure toward RAN 
as soon as the UE is identified (IMSI). The IMSI is only stored in the RAN for the duration of the RRC Connection. 

There are two functions that are co-ordinated. 
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1) Paging coordination is described in 5.9.1 of 25.410 [10]; and 

2) Relocation coordination that is described in 8.7.5 in 25.413 [9]. 



7 Call control 

7.1 General Aspects 

The following technical requirements are applied to support multimedia in GSM/UMTS. 

1) GSM/UMTS shall enable the provisioning of multimedia services and multivendor interworking between UE 
and network. 

2) Handover and roaming to and from GSM shall be supported provided GSM is capable of supporting the 
ongoing media service. 

3) For multimedia services the standardized multimedia protocol shall be run transparently via a PDP-context or a 
CS connection established using GSM SM/CC . This allows transparent hand-over and roaming between GSM 
and UMTS provided that GSM supports the QoS requirements. 

4) SIP from the IETF shall be the multimedia call control supported over the PS domain, where the network 
functional entities for multimedia support are within the PLMN. 

NOTE: Other multimedia protocols can be supported e.g. H.323 transparently over the PS domain . In these 

cases, the multimedia functional entities shall be outside of the PLMN. Support of terminating calls for 
these protocols are outside the scope of these specifications. 

5) H.324M shall be supported within the CS domain. 

Figure 7.1 illustrates the realisation of the multimedia service based on requirement 3. 'Multimedia Protocol' indicates 
the functionality either inside the communicating user's terminal or a server (e.g. SIP server). It is essentially a control 
function both for user plane and control plane for the multimedia communication. 
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Figure 7.1 : Support of multimedia making use of GSM SM/CC 

7.2 Domain selection for mobile terminated calls from the 
PSTN/CS domain 



7.2.1 



Introduction 



It is an operator's decision whether mobile terminated calls from the PSTN/CS domain are routed first to the CS 
domain, or to the IM subsystem. Both options may co-exist within one operator's network. 
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7.2.2 Calls directed to the CS domain 

When the mobile terminated call set-up arrives at a G-MSC server or G-MSC, then the G-MSC Server or G-MSC 
interrogates the HSS for routing information. The HSS decides on the way the call shall be treated next (e.g. IM CN 
subsystem, CS domain (e.g. the subscriber is roaming in a legacy network), service platform involvement). According 
to the decision, the HSS returns information that will make the G-MSC progress the call towards an MGCF (for onward 
handling in the IMS), a VMSC or to provide further processing (e.g. invoke CAMEL G-MSC processing). 

7.2.3 Calls directed to the IMS 

When the mobile terminated call set-up arrives at a MGCF, then the MGCF passes the session to an I-CSCF which 
interrogates the HSS for routing information. The HSS returns information that will enable the I-CSCF to progress the 
call towards an S-CSCF. From the S-CSCF the session may be re-directed to the CS domain or may continue in the 
IMS. 

7.3 Routing sessions from the IMS to the CS Domain 

If a subscriber is subscribed to both the CS domain and the IMS, then there may arise the need to route sessions that 
arrived in the IMS to the CS domain using a number related to the subscriber's MS-ISDN. All sessions which are 
forwarded from the IMS to the CS domain shall enter the CS domain through a G-MSC or G-MSC Server. The G-MSC 
or G-MSC Server will handle the session as a mobile terminating call. 



8 Support of IM CN Subsystem services 

8.1 Context activation and registration 

The IP address is allocated to UE either by GPRS or some other means e.g. by DHCP The UE shall use IP addresses 
assigned to it for, but not limited to, the following: 

the exchange application level signalling (e.g., registration, CC) with the serving CSCF from the access network 
currently used, 

application level registration to IM CN subsystem as an address used to reach the UE 

an address used to reach the UE for multimedia calls. 

In GPRS, the terminal is associated with an IP address when the primary PDP context is activated. The IP address used 
for the purpose described above can be: 

the IP address obtained by the UE during the activation of a primary PDP context (e.g. if the UE does not have 
any existing PDP context active or desires to use a different IP address) 

the IP address of one of the already active PDP contexts. 

In the following, a description of the order in which the registration procedure is executed need and how the IP address 
is allocated is shown. Figure 8.1 shows what procedures and in which order they are performed during the registration. 
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Figure 8.1 : Registration 



The following steps are performed: 



1. the bearer level registration is performed (e.g. when the terminal is switched on or upon explicit indication from 
the user). 

2. the PDP context activation is done. The UE has two options: 

activate a primary PDP context and obtain a new IP address (e.g. if the UE does not have any existing PDP 
context active or desires to use a different IP address) 

activate a secondary PDP context and re-use the IP address of one of the already active PDP contexts. 

3. UE performs the CSCF discovery procedure, where the UE discovers a proxy CSCF [11]. 

There can be time gaps between these procedures and the following one. For instance, the UE may perform PDP 
context activation and the CSCF discovery, but not the application level registration. The UE may use the activated 
PDP context for other types of signalling, e.g. for CSCF discovery. 

4. UE performs application level registration by providing the IP address obtained at step 2 to the CSCF selected at 
step 3. The IP address used for signalling purposes is allocated in association with PDP context activation and 
not on an incoming call basis. 

The discovered P-CSCF forwards the registration on to the UE's home network where a S-CSCF [11] is assigned 
and the registration takes place. This registration associates the P-CSCF with the UE. 

From the S-CSCF point of view, the P-CSCF is where the UE is reachable for mobile-terminated call control 
signalling and any other type of mobile terminated signaling. 

Whether the procedures are activated individually by the UE or some of them are performed automatically depends on 
implementation of the terminal and on the UE's configuration. For instance, the multimedia application in the UE could 
start the application level registration and steps 2-4 would have to be executed in response to support the operation 
initiated by the application. Interaction with the UE may happen during these steps. 
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8.2 Location management 

8.2.1 Registration concepts for a subscriber roaming into CS domain 

Figure 8.2 shows the registration concept for a subscriber, who access IM services in the home network, roaming into a 
CS domain. 

UMTS (R99-CS, and PS-IM/CS -CS 

in case of non-IP transport) 
subscriber data download 
GSM (CS) subscriber data download 




Figure 8.2: A roaming model for registration in a CS domain 

NOTE: The above figure shows one configuration where the SGW is needed. Other configurations are possible as 
well [1]. 

The detailed message sequence chart for a subscriber roaming into a CS domain and accessing an IM application is 
shown in figure 8.3. 
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Figure 8.3: Message sequence for roaming into a CS domain 
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1 . The UE initiates the Location Update procedure with the MSC/VLR of the visited network. The LU message 
contains the IMSI of the subscriber. 

2. The authentication is performed as per the existing 3GPP specifications for the CS domain. 

3. The MSC/VLR initiates the MAP Location Update procedure towards the HSS of the user via SOW. The HSS 
stores the VLR address etc. The message contains IMSI and other parameters as defined in the 3GPP 
specifications for the CS domain. The SGW performs SS7 transport to/from IP conversion. 

4. The HSS provides the subscriber data for the roaming user to VLR by sending MAP Insert Subscriber Data 
message via SGW. The message contains IMSI and other necessary parameters as defined in the 3GPP 
specification for both lu and A/Gb mode. The message is passed through the SGW transparently while the SS7 
to/from IP conversion is performed in SGW. 

5. The serving VLR then acknowledges the receipt of the subscriber data to the HSS via SGW. 

6. The HSS acknowledges the completion of location updating procedure to the MSC/VLR via SGW. 

7. The MSC/VLR acknowledges the completion of location updating procedure to the UE. 

8. The HSS sends the MAP Cancel Location message to the old MSC/VLR (optional procedure). 

9. Location cancellation is acknowledged to the HSS by the old MSC/VLR. 

NOTE 1 : The steps 8 and 9 above assume that the UE was previously registered to a CS domain . 

NOTE 2: The MAP messages between the MSC/VLR and HSS are passed transparently via SGW. The SGW does 
not interpret the MAP messages in anyway, but performs only the lower level conversion between SS7 
and IP. This is in accordance with the TS 23.002 for SGW [1]. 



Efficient use of radio resource 



This clause captures the technical requirements to ensure efficient use of the radio resource in the UMTS access 
network. The radio resource is considered to be a scarce resource and therefore every opportunity shall be taken to 
optimize its use. 

It shall be possible to re-apply PS domain pre-release 5 mechanisms for efficient use of radio resource. 

Additional requirements for efficient use of the radio spectrum for release 5 SIP signalling include the following: 

UMTS shall support mechanisms to optimize transport of SIP signaling packets over the radio interface, 
typically by compressing the SIP signaling messages and by compressing the IP and transport layer protocol 
headers that carry these SIP messages. 

The chosen solution(s) shall be extensible to facilitate the incorporation of new and improved compression 
algorithms in a backward compatible way as they become available. 

The chosen solution(s) should work in roaming scenarios. 

Application specific compression shall minimize impacts on existing UMTS release e.g. it could be defined 
between the UE and associated application server, e.g. at the SIP Client and at the first SIP Proxy. 

Support of SIP signalling compression is mandatory in the UE and P-CSCF for IMS. The actual usage of compression 
is optional but highly preferable and is subject to operator policies. See 24.229 for more details [23]. 



£75/ 



3GPP TS 23.221 version 5.11.0 Release 5 



37 



ETSI TS 123 221 V5.11.0 (2004-09) 



Annex A (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


April 
2001 


SA#11 


SP-010122 


- 




Creation of v. 4.0.0 


2.0.0 


4.0.0 


April 
2001 


SA#11 


SP-010119 


001 




Creation of v. 5. 0.0 


4.0.0 


5.0.0 


June 
2001 


SA#12 


SP-010333 


006 




Removal of Editor's notes 


5.0.0 


5.1.0 


June 
2001 


SA#12 


SP-010333 


008 




Clarification of text on Location Area Update 


5.0.0 


5.1.0 


June 
2001 


SA#12 


SP-010333 


Oil 




Editorial Corrections to section 5.2 


5.0.0 


5.1.0 


June 
2001 


SA#12 


SP-010333 


012 




The introduction of area concepts for GERAN 


5.0.0 


5.1.0 


June 
2001 


SA#12 


SP-010333 


013 




Basic principles for MS controlled Cell 


5.0.0 


5.1.0 


October 
2001 


SA#13 


SP-010514 


016 




Correction on CSCF discovery to align with 23.228 


5.1.0 


5.2.0 


October 
2001 


SA#13 


SP-010514 


003 


2 


Efficient use of the Radio Resource Technical Requirements 


5.1.0 


5.2.0 


January 
2002 


SA#14 


SP-010712 


002 


6 


Routing of MT call from PSTN to CS or IMS 


5.2.0 


5.3.0 


January 
2002 


SA#14 


SP-010712 


014 


1 


Use of the terms lu mode and A/Gb mode 


5.2.0 


5.3.0 


January 
2002 


SA#14 


SP-010712 


015 


2 


Editorial corrections 


5.2.0 


5.3.0 


January 
2002 


SA#14 


SP-010712 


017 




Removal of Editor's notes 


5.2.0 


5.3.0 


January 
2002 


SA#14 


SP-010712 


020 




GGSN & P-CSCF in the HPLMN 


5.2.0 


5.3.0 


January 
2002 


SA#14 


SP-010712 


021 


1 


Routing Calls from the IMS to the CS domain 


5.2.0 


5.3.0 


January 
2002 


SA#14 


SP-010712 


025 


1 


IPv6 requirements for 3GPP UE(s) 


5.2.0 


5.3.0 


March 
2002 


SA#15 


SP-020135 


026 


1 


Renaming of R-SGW 


5.3.0 


5.4.0 


March 
2002 


SA#15 


SP-020135 


027 


1 


Allocation of unique prefixes to IPv6 terminals 


5.3.0 


5.4.0 


March 
2002 


SA#15 


SP-020135 


028 




Compression use for SIP Signalling 


5.3.0 


5.4.0 


June 
2002 


SA#16 


SP-020313 


32 


2 


CS domain signalling requirements: MSC and RNC 
behaviour relating to handover and cell reselection 


5.4.0 


5.5.0 


June 
2002 


SA#16 


SP-020313 


33 




CR related to the discussion in S2-021074. 


5.4.0 


5.5.0 


Septemb 
er 2002 


SA#17 


SP-020533 


34 


1 


Change of reference to IPv6 host requirements 


5.5.0 


5.6.0 


Decembe 
r2002 


SA#18 


SP-020775 


037 


1 


Update to duplicate text 


5.6.0 


5.7.0 


Decembe 
r2002 


SA#18 


SP-020775 


038 


1 


Completion of recent change on CS domain signalling 
requirements 


5.6.0 


5.7.0 


Septemb 
er 2003 


SA#21 


SP-030379 


040 


1 


Combination of service domains 


5.7.0 


5.8.0 


March 
2004 


SA#23 


SP-040036 


045 




Interaction between Shared Network in Connected mode, 
reject of Mobility Management procedures and Common Id 


5.8.0 


5.9.0 


June 
2004 


SA#24 


SP-040318 


049 


1 


IPv4 based IMS 


5.9.0 


5.10.0 


Septemb 
er 2004 


SA#25 


SP-040522 


050 




Referencing TR 23.981 


5.10.0 


5.11.0 



£75/ 



3GPP TS 23.221 version 5.11.0 Release 5 



38 



ETSI TS 123 221 V5.11.0 (2004-09) 



History 


Document history 


V5.4.0 


March 2002 


PubHcation 


V5.5.0 


June 2002 


PubHcation 


V5.6.0 


September 2002 


PubHcation 


V5.7.0 


December 2002 


PubHcation 


V5.8.0 


September 2003 


PubHcation 


V5.9.0 


March 2004 


PubHcation 


V5.10.0 


June 2004 


PubHcation 


V5.11.0 


September 2004 


PubHcation 



£75/ 



